fix(linter): detect root lint target added in same generator run#35296
Merged
FrozenPandaz merged 1 commit intomasterfrom Apr 27, 2026
Merged
fix(linter): detect root lint target added in same generator run#35296FrozenPandaz merged 1 commit intomasterfrom
FrozenPandaz merged 1 commit intomasterfrom
Conversation
When generating a new non-root project, isMigrationToMonorepoNeeded relied on the project graph to decide whether to split the root eslint config into a base config. The graph reflects the filesystem, so it missed root lint targets written to the tree earlier in the same generator run, deferring the split to a second invocation. Check the tree first for an explicit root lint target. Only consult the graph (which encodes plugin-inferred targets) when @nx/eslint/plugin is registered and the tree did not resolve the question.
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nx-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
View your CI Pipeline Execution ↗ for commit ec74533
☁️ Nx Cloud last updated this comment at |
FrozenPandaz
approved these changes
Apr 27, 2026
ShwethaSundar
pushed a commit
to ShwethaSundar/nx
that referenced
this pull request
Apr 27, 2026
…l#35296) ## Current Behavior When a generator adds a lint target to the root project and then creates a new non-root project in the same run, the root eslint config is not split into a base config on that run. Subsequent projects created afterwards (in the same run or in separate runs) end up wired incorrectly, and users have to re-run the generator to get the migration to actually happen. ## Expected Behavior The root eslint config is split into a base config on the first run where a non-root project is created alongside a root lint target, so projects are wired correctly without requiring a second invocation. ## Implementation Notes `isMigrationToMonorepoNeeded` previously relied on `createProjectGraphAsync()` to detect the root lint target. The project graph reflects the filesystem at its last rebuild and misses targets written to the tree earlier in the same generator run. The check now reads the tree first via `getProjects(tree)`. The project graph is only consulted as a fallback when `@nx/eslint/plugin` is registered, since plugin-inferred targets do not appear on the tree — preserving the behavior introduced in nrwl#23147. ### Known gaps (not addressed) The symmetric in-flight cases on the inferred branch remain open: - a root eslint config file written during the same generator run with `@nx/eslint/plugin` already registered, and - `@nx/eslint/plugin` registered in `nx.json` during the same run with a root config already on disk. Closing them would require reimplementing `@nx/eslint/plugin`'s `createNodes` pipeline against the tree — the maintenance burden nrwl#23147 explicitly avoided. No known user report exercises those paths today. ## Related Issue(s) Fixes nrwl#34531
FrozenPandaz
pushed a commit
that referenced
this pull request
Apr 28, 2026
) ## Current Behavior When a generator adds a lint target to the root project and then creates a new non-root project in the same run, the root eslint config is not split into a base config on that run. Subsequent projects created afterwards (in the same run or in separate runs) end up wired incorrectly, and users have to re-run the generator to get the migration to actually happen. ## Expected Behavior The root eslint config is split into a base config on the first run where a non-root project is created alongside a root lint target, so projects are wired correctly without requiring a second invocation. ## Implementation Notes `isMigrationToMonorepoNeeded` previously relied on `createProjectGraphAsync()` to detect the root lint target. The project graph reflects the filesystem at its last rebuild and misses targets written to the tree earlier in the same generator run. The check now reads the tree first via `getProjects(tree)`. The project graph is only consulted as a fallback when `@nx/eslint/plugin` is registered, since plugin-inferred targets do not appear on the tree — preserving the behavior introduced in #23147. ### Known gaps (not addressed) The symmetric in-flight cases on the inferred branch remain open: - a root eslint config file written during the same generator run with `@nx/eslint/plugin` already registered, and - `@nx/eslint/plugin` registered in `nx.json` during the same run with a root config already on disk. Closing them would require reimplementing `@nx/eslint/plugin`'s `createNodes` pipeline against the tree — the maintenance burden #23147 explicitly avoided. No known user report exercises those paths today. ## Related Issue(s) Fixes #34531
Contributor
|
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Behavior
When a generator adds a lint target to the root project and then creates a new non-root project in the same run, the root eslint config is not split into a base config on that run. Subsequent projects created afterwards (in the same run or in separate runs) end up wired incorrectly, and users have to re-run the generator to get the migration to actually happen.
Expected Behavior
The root eslint config is split into a base config on the first run where a non-root project is created alongside a root lint target, so projects are wired correctly without requiring a second invocation.
Implementation Notes
isMigrationToMonorepoNeededpreviously relied oncreateProjectGraphAsync()to detect the root lint target. The project graph reflects the filesystem at its last rebuild and misses targets written to the tree earlier in the same generator run.The check now reads the tree first via
getProjects(tree). The project graph is only consulted as a fallback when@nx/eslint/pluginis registered, since plugin-inferred targets do not appear on the tree — preserving the behavior introduced in #23147.Known gaps (not addressed)
The symmetric in-flight cases on the inferred branch remain open:
@nx/eslint/pluginalready registered, and@nx/eslint/pluginregistered innx.jsonduring the same run with a root config already on disk.Closing them would require reimplementing
@nx/eslint/plugin'screateNodespipeline against the tree — the maintenance burden #23147 explicitly avoided. No known user report exercises those paths today.Related Issue(s)
Fixes #34531